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Abstract 

ENCOMPASS is an example integrated software engineering environment being con- 
structed by the SAGA project. ENCOMPASS supports the specification, design, construction 
and maintenance of efficient, validated, and verified programs in a modular programming 
language. In this paper, we present the life-cycle paradigm, schema of software configurations, 
and hierarchical library structure used by ENCOMPASS. In ENCOMPASS, the software life- 
cycle is viewed as a sequence of developments, each of which reuses components from the previ- 
ous ones. Each development proceeds through the phases planning, requirements definition, 
validation, design, implementation, and system integration. The components in a software sys- 
tem are modeled as entities which have relationships between them. An entity may have 
different versions and different views of the same project are allowed. The simple entities sup- 
ported by ENCOMPASS may be combined into modules which may be collected into projects. 
ENCOMPASS supports multiple programmers and projects using a hierarchical library system 
containing a workspace for each programmer; a project library for each project, and a global li- 
brary common to^all projects. A prototype implementation of ENCOMPASS is being construct- 
ed on the UNIX operating system using an existing revision control system and many tools 
developed by the SAGA project. 


1. Introduction 

It is widely acknowledged that software is both difficult and expensive to produce and maintain. 
One solution to this problem is the use of software engineering environments which integrate a number 
of tools, methods, and data structures to provide support for program development and/or mainte- 
nance[l5,34,42,43j. The SAGA project is investigating both the formal and practical aspects of provid- 
ing automated support for the full range of software engineering activities[2,5,7,2l]. A SAGA-based 
software tool or environment is created by combining standard components which are generated by 
This research is supported by NASA grant NAG 1-138. 
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meta-tools . ENCOMPASS is an example software engineering environment being developed by the 
SAGA group. In this paper we describe the life-cycle paradigm, schema of software configurations, and 
hierarchical library structure used by ENCOMPASS. 

It has been suggested that modular programming\ 35] and the top-down development of pro- 
grams^] can help reduce the difficulty of program development and maintenance. By logically dividing 
a monolithic program into a number of modules we reduce the knowledge required to change fragments 
of the system and decrease the apparent complexity. By using stepwise refinement to create a concrete 
implementation from an abstract specification we divide the decisions necessary for an implementation 
into smaller, more comprehensible groups. A number of modern programming languages support modu- 
lar programming[9,26,28] and environments to support modular programming have been designed[4] and 
constructed[41,50], Methods to support the top-down development of programs have been devised[l9,36] 
and put into use[37]. 

A life-cycle model describes the sequence of distinct stages through which a software product 
passes during its life-time[l l]. There is no single, universally accepted model of the software life- 
cycle^, 51], The stages of the life-cycle generate software components such as specifications of various 
forms, code written in programming languages, and many types of documentation. Configuration 
management is concerned with the identification, control, auditing, and accounting of components pro- 
duced and used in software development and maintenance[l]. Configuration control systems[l0,23,38] 
and models of software configurations^, 33] have been suggested as aids to configuration management. 
Life-cycle and configuration models that are understood and accepted by everyone involved can enhance 
communication, aid project management and increase product quality. 

ENCOMPASS is a software engineering environment concerned with the construction and mainte- 
nance of efficient, validated, and verified programs in a modular programming language. The software 
life-cycle is viewed as a sequence of developments, each of which reuses components from the previous 
ones. Each development passes through the stages planning, requirements definition, validation, design, 
implementation, and system integration. An executable specification language is used to produce pro- 
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grams for experimentation, evaluation, and validation as early as possible in the development process. 
The components in a software project are modeled as entities which have relationships between them, 
and different views of the same project are allowed. The simple entities supported by ENCOMPASS 
may be combined into modules which may be collected into projects. ENCOMPASS supports multiple 
programmers and projects using a hierarchical library system containing a workspace for each program- 
mer; a project library for each project, and a global library common to all projects. 

In section two, we describe the life-cycle paradigm on which ENCOMPASS is based and in section 
three, we present its schema of software configurations. In section four, we describe the hierarchical 
library structure used by ENCOMPASS and in section five, we discuss a prototype implementation of 
ENCOMPASS which is being constructed on the UNIX operating system. In section six, w r e describe our 
plans for extending ENCOMPASS and in section seven, we summarize and draw some conclusions from 
our experience. 

2. The Software Life-Cycle 

ENCOMPASS is used by a programming team to construct and/or maintain a system , which may 
contain programs written in different languages. Modular programming techniques may be supported 
directly by the languages[9,2G,28] or by coding conventions and/or a pre-processor[46]. A system must 
usually satisfy both performance constraints , such as speed or storage requirements, and design con- 
straints , such as proper modularization and documentation. Verification guarantees that software com- 
ponents are correct and complete relative to each other, while validation shows that a system performs 
the functions desired by the cus/omersjll]. 

It has been suggested that the reuse of software can significantly reduce the cost of program 
development[l7], and systems which contain libraries of previously coded modules and/or a number of 
standard designs for program have been proposed[25,29j. In ENCOMPASS, any software component or 
group of components can be saved for later reuse in a central library. The library supports a number of 
concurrent projects, both accepting and supplying components for reuse in all phases of the life-cycle. 
ENCOMPASS supports the reuse of all the components produced in the development of a system. In 
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addition to source and object code, documentation, forma! specifications, proofs of correctness, test data 
and test results can all be stored in the central library for reuse. 

Figure 1 shows the proposed software life-cycle which consists of a sequence of developments. 
These developments might produce a series of prototypes which are used in the production of a system. 
In this case, each prototype would be evaluated and the results incorporated in the next stage of produc- 
tion. During the next stage, all the materials from the development of the prototype would be available 
for reuse. A sequence of developments might also produce a family of systems for use in different 
operating environments or with different optional features. In this case, all the materials from the 
development of the family would be available for reuse in the development of new family members. A 
sequence of developments might also represent what is traditionally called the maintenance phase of a 
development. A system, which has been constructed and installed, may have to be modified, corrected, 
or enhanced. In ENCOMPASS, this is seen as a new development, but with all the products of the pre- 
vious development available for reuse. In this way ENCOMPASS supports both development and 
maintenance with the same methods and tools. 

ENCOMPASS supports program development by successive refinement using the Vienna Develop- 
ment Method[l9,37]. In this method, programs are first written in a language combining elements from 
conventional programming languages and mathematics. These abstract programs are then incrementally 
refined into programs in an implementation language. The refinements are performed one at a time and 
each is verified before another is applied. Therefore,, the final program produced by the development 
and the original abstract program are equivalent. In ENCOMPASS, abstract programs may be written 
in the executable specification language PLEASE[44], which is an extension to the language Path Pas- 
cal^] allowing routines and data types to be specified using predicate logic. A procedure or function 
may be specified using pre and post-conditions and an invariant for a data type may be specified. 

It has been proposed that software development may be viewed as a sequence of transformations 
between specifications written at different linguistic levels[ 27] and systems to support similar develop- 
ment methodologies have been constructed[32|. ENCOMPASS supports this view of software develop- 
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ment by allowing abstract, predicate logic based definitions of data types or routines to be transformed 
into successively more concrete realizations. The use of executable specifications allows two or more 
linguistic levels to be run in parallel and compared for the purposes of verification or debugging. 
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The development steps in ENCOMPASS may be much smaller than in the traditional software 
life-cycle. For example, a system might go through a very large number of prototypes before delivery to 
the customers. Developments may also be composed hierarchically. For example, if a system is very 
large and complex, the production of an executable specification for the system may in itself be a com- 
plete development. If the system is composed of several major components, the production of each com- 
ponent might also be a complete development. By dividing the life-cycle into small steps using the 
mechanisms of sequential and hierarchical composition, ENCOMPASS allows each step to be smaller and 
more comprehensible and thereby increases management’s ability to trace and control the project. 

2.1. Software Development 

Each development passes through the phases: planning, in which the problem is defined and it is 
determined if a computer solution is feasible and cost effective; requirements definition, which produces a 
high-level specification of the system to be produced; validation, which determines that the system 
described by the specification will satisfy the customers; design, in which the basic structure of the sys- 
tem is described; implementation, in which components of the system are constructed; and system 
integration, in which the components are integrated into a complete system, acceptance tests are per- 
formed, and the product is delivered. This structure is Fairley’s phased life-cycle model[ll], extended to 
support the Vienna Development Method and the use of an executable specification language. 

The Vienna Development Method can aid in the production of correct software by allowing a sys- 
tem to be produced by a sequence of refinements, each of which is shown correct before proceeding 
further in the development. The use of an executable specification language allows each refinement to 
be verified by testing techniques as well as by mathematical proof. Abstract programs can also enhance 
the design phase by allowing experiments to be performed which influence design decisions, and the vali- 
dation phase by allowing the customers to evaluate a running system early in the development process. 
We believe the the early validation will aid in lowering the cost of correcting errors made during require- 
ments definition. Each phase of the development produces certain components which may be used 
and/or updated during the rest of the life-cycle[ll]. 
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2.1.1. Planning 


In the planning phase the problem to be solved is defined and it is determined if a computer solu- 
tion is feasible and cost effective[ll]. Alternative solutions to the problem are considered and compared 
for cost effectiveness and preliminary plans and schedules for the project are created. In ENCOMPASS, 
these processes can be enhanced by the use of abstract programs as prototypes for experimentation and 
evaluation. This phase produces the two natural language documents[ll]: the system definition , and the 
preliminary project plan . The system definition describes the original problem, gives justifications for 
the proposed computer system as a solution, and contains acceptance criteria which describe the stand- 
ards and procedures to be used for evaluating the system. The project plan describes the milestones and 
specific products to be produced as well as the organizational structure to be used by the project. Once 
the problem has been defined and it is clear that a computer solution will be cost effective, a more 
detailed description of the system requirements is needed. 

2.1.2. Requirements Definition 

Requirements definition determines the functions and qualities of the software to be produced by 
the developmental]. This phase concentrates on the needs and desires of the customers as they affect 
the external system interface, rather than the internal structure of the software to be produced. This 
phase produces[ll] the software requirement specification , and preliminary versions of the users manual , 
and the software verification plan. The software requirement specification precisely describes each 
requirement of of the software to be produced. It contains a functional specification of the system, 
descriptions of the external interfaces, and performance and design constraints. The users manual is 
documentation for the customers. It contains an overview of the system, tutorials on various system 
functions, and detailed users documentation on all system commands. The software verification plan 
describes the methods to be used in verifying that the system produced by the development satisfies the 
software requirement specification. Although the requirement specification describes a software system, 
it is not known if any system which satisfies the specification will satisfy the customers. In ENCOM- 
PASS, we extend Fairley’s phased life-cycle model to include a separate phase for customer validation. 
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2.1.3. Validation 


The validation phase attempts to show that a system which satisfies the software requirements 
specification will also satisfy the customers, that is, that the requirements specification is valid. If not, 
then the requirements specification should be corrected before the development proceeds to the costly 
ph ases of design, implementation, and system integration. In the validation phase, the developers 
interact with the customers and the system validation summary is produced. This document describes 
the customers evaluation of the software requirements specification. It lists any problems encountered 
and the solutions agreed upon. 

Traditionally, producing a correct specification is a difficult task. The users of the system may not 
really know what they want and they may be unable to communicate their desires to the development 
team. If the specification is in a formal notation it may be an ineffective medium for communication 
with the customers, but natural language specifications are notoriously ambiguous and incomplete. Pro - 
totyping\ 14,22], and the use of executable specification languages[20,31,52] have been suggested as partial 
solutions to this problems. Providing the customers with prototypes for experimentation and evaluation 
may increase customer/developer communication and enhance the validation process. 

In ENCOMPASS, we extend Fairley’s model to include software requirements specifications which 
are a combination of natural language and abstract programs written in PLEASE. PLEASE programs 
are prototypes which can be used for experimentation and evaluation, and a formal specification of a 
part of the system to be produced which can be used throughout the rest of the life-cycle. By providing 
executable programs early in the development process, errors in the requirements specification may be 
discovered and corrected before the internal structure of the system has been defined. 

2.1.4. Design 

In the design phase, the structure of the software system is defined[ll]. The components of the 
system; their interfaces; the flow of control and data between components; and global data abstractions, 
structures and formats are all designed and documented. This phase produces the software design 
specification\ 1 1 j, which provides both a record of the design decisions made and a blueprint for the 
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implementation phase. This document is created in two steps: first the architectural design 
specification, and then the detailed design specification. In ENCOMPASS, the software design 
specification may contain PLEASE programs which describe the modular structure, and possibly the 
function, of parts of the system. These programs may be used as prototypes in experiments performed 
to guide the design process. They may also be used to verify parts of the design using techniques from 
the Vienna Development Method[l9], During the implementation phase, these PLEASE programs can 
be refined into programs in the implementation language Path Pascal. 

2.1.5. Implementation 

In the implementation phase, programming language code for the system is produced[ll]. Each 
separately constructed module must be written, compiled, debugged, and documented. Each module 
must also be shown to satisfy the requirements and design specifications. In ENCOMPASS, this may be 
accomplished using mathematical reasoning[l6,49), testing[l3, 18,30], technical review[47], or inspection. 
The use of executable specifications enhances the verification of system components using either testing 
or proof techniques. The executable specification for a component can be used as a test oracle against 
which the implementation can be compared. Since the specification is formal, proof techniques may be 
used which range from a very detailed, completely formal proof using mechanical theorem proving to a 
formal argument presented as in a mathematics text. PLEASE provides a framework for the 
rijor<Mis[l9] development of programs. Although detailed formal proofs are not required at every step, 
the framework is present so that they can be constructed if necessary. Parts of a project may use 
detailed formal verification while other, less critical parts may be handled using less expensive tech- 
niques. Once the separate components have been constructed and verified, they must be integrated and 
verified as a system. 

2.1.0. System Integration 

In the system integration phase, separately implemented modules are integrated into larger and 
larger units, each of which is shown to satisfy the specifications] 1 1], If errors are found and corrected in 
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a low level module, the correctness of any previously verified modules which use the low level module 
may have to be redetermined. This phase produces the software verification summan/[ll] which 
describes the results of all reviews, inspections, tests, and formal verifications which have been per- 
formed. ENCOMPASS provides tools to aid in the hierarchical integration and testing of programs. 
When using these tools, all modules which are used by a particular module are tested before tests of that 
module are begun. When the final integration has been performed the acceptance tests are performed, 
the product is delivered and the development is complete. 

After the development has been completed a development legacy\ 11] is written. The legacy sum- 
marizes the development and provides a permanent record of what problems and solutions were encoun- 
tered. This document provides both an aid to management in evaluating the effectiveness of the tools 
and methods used on the project, and an index to the development to be used by other developers wish- 
ing to reuse the components produced. The evaluation and reuse of components is further enhanced by 
the use of a configuration model to describe software components and their relationships. 

3. A Model for Software Configurations 

The ENCOMPASS model of software configurations is a refinement of the model presented in[2l]. 
It is similar to the entity-relationship model[8] and uses the concepts of aggregation and generaliza - 
fton[39,40]. The model provides us with a natural way to describe software and also has a convenient 
representation on conventional computer systems which can be used as the basis for software engineer- 
ing environments. 

3.1. Entities and Relationships 

An entity is a distinct, uniquely named component. An example of an entity is a file, which could 
contain the source code for a program, some test data, or an executable program. An entity may have 
attributes which describe its properties or qualities. For example, a file could have attributes such as 
“size”, “owner*’, “permissions 7 *, and “modify time’’. An entity may be decomposed into smaller com- 
ponents, which may or may not be entities themselves. For example, a file might be composed of para- 
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graphs of text or statements in a programming language. 


Two or more entities may have a relationship between them. For example, the entities containing 
the source and object code for a routine might have the relationship “compiled-from” between them. A 
relationship may also have attributes, for example the time the compile took place. A group of entities 
with a relationship between them may be abstracted into an aggregate entity. This entity would have 
entities as the values of some or all of its attributes. For example the specification 2 , body, object code 
and load module for a group of routines might be abstracted into a single entity called a “code module”. 
An aggregation hierarchy describes the way components are combined to form more and more complex 
structures. 

A generalization is an abstraction which allows a number of distinct components to be grouped 
together into a single named component. A generalization hierarchy shows the way components with 
similar attributes are grouped into more and more general components. In our model, the set of entities 
which share certain attributes may be viewed as a generic entity. For example, the specification and 
body for a module might share the attributes “module name" and “type” (for example, source code, 
object code, test data or text). These two entities might then be grouped together into a generic com- 
ponent representing the source code for the module. 

An entity has an internal state which may change with time. A version represents the state of an 
entity at a particular point in time. A version of an aggregate entity denotes the versions of all the enti- 
ties of which it is composed. The same version of an entity may be used in many different composite 
entities or versions of the same aggregate entity. 

3.2. Components Supported by ENCOMPASS 

The aggregation hierarchy for ENCOMPASS contains three levels: simple entities may be com- 
bined into aggregates called modules , which may be collected into aggregates called projects . An entity 

2 

In PLEASE a separately compiled module may have a specification, which describes the interface and func- 
tion of the module, and a body, which contains the implementation of the module. The two are compiled as a unit 
to produce a single piece of object code which may be linked with other separately compiled modules to form an ex- 
ecutable load module. 
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which does not have entities as the values of any of its attributes is known as a simple entity . An exam- 
ple of a simple entity is a file containing the source code for a routine with the attributes “language”, 
“modify time”, and “size”. A module is an aggregate entity composed of other entities which are closely 
related or have some common property. For example, a code module could contain the specification, 
body, object code, and load module for a program. The module would have attributes specification, 
body, object and load with the appropriate entities as values. A project is an aggregate entity composed 
of modules. For example all the modules used in developing a program might be be grouped together 
into a project. 

The generalization hierarchy for ENCOMPASS includes several sub-classes for both modules and 
simple entities. A module may be: a code module , which contains entities associated with the production 
and debugging of code; a test module , which contains materials for the testing of other modules such as 
sets of test data and test drivers or harnesses; a proof module , which contains entities used in the proof 
of a refinement; a document module , which contains entities used in the production of documentation; or 
a history module , which contains components used to track the history of a project. Simple entities may 
be: code components , including source code, object code, load modules and include files; makefile s[\2], 
which contain instructions for compilation, linking, and testing; test data , such as the input or correct 
output from a program; proof data , which might be input for a mechanical theorem prover; and docu- 
ment data , such as input to text processing programs. 

3.3. Views 

A view is a mapping from names to components. A project under development has a distinguished 
base view which describes the entities of the system being designed and the primitive relationships 
between these entities. Other views of the project arc produced from this base view by selecting, and 
possibly renaming, certain entities with particular attributes. For example, the development and quality 
assurance teams may have different views of the software system being developed by the project. The 
development team may use a view of the system which includes all the specifications and software being 
developed. However, the quality assurance team may have a different view which contains the 
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specifications, executable code and, in addition, the test cases. Views may be used to abstract the phases 
of the project corresponding to planning, requirements definition, validation, design, implementation, 
and system integration. Views may be used to identify a slice of the software being developed, for exam- 
ple, in order to restrict the activities of a programmer to a particular group of modules. Views may also 
be constructed to represent the effect of a modification on the rest of a system. In ENCOMPASS, access 
to components is controlled through the use of views and a hierarchical library structure. 

4. Library Structure 

Figure 2 shows the library structure used by ENCOMPASS which contains a workspace for each 
programmer, a project library for each project, and a global library common to all projects. Each pro- 
grammer controls his own workspace while each project leader controls the library for his project and 
the librarian controls the global library. All components which are accessed by more than one program- 
mer reside in the project or global libraries where they are controlled by either the project leader or the 
librarian. 

A programmer accesses the components he is working with through his workspace. The workspace 
may actually contain these components, or it may reference components in the project or global libraries 
through a view. A workspace may reference the working copy of an components or a version fixed at 
some earlier point in time. The project library contains components that must be available to all the 
personnel on a particular project, and can aid the project leader in controlling and monitoring the 
development. The project leader controls the components in the project library by controlling access 
and the views into the library. 

For example, a component containing the specification and body for a module might reside in the 
project library. Assume two programmers are working on the module. Programmer A is assigned the 
task of writing a specification for the module. Therefore lie may access the working copy of the 
specification from his workspace, but he has no access to the body for the module. Programmer B is 
assigned the task of writing the body from the completed specification. Therefore his workspace con- 
tains references to a fixed version of the specification and the working copy of the body. 
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The global library contains components available for reuse on all projects and is read-only to all 
but the librarian . The librarian controls which components will be saved for reuse and how they will be 
available. When a project leader feels that a component may be useful for reuse on other projects he 
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submits it to the librarian who performs a component review to determine if the component meets the 
minimum standards for correctness, reliability, documentation, and generality. If the component meets 
these standards then the librarian must decide how to index the component for later retrieval. Each 
component available for reuse is associated with a number of key words which describe its structure, 
function and quality . Components in the library may be accessed either individually or in groups. To 
search the library for components that may be useful, a programmer uses simple retrieval tools, specify- 
ing the key words in which he is interested using a regular expression. The tool returns a list of com- 
ponents, each of which is associated with the key words he specified. The programmer may then create 
a reference to or copy of any components which are of interest in his workspace and examine them in 
more detail. 

For example, suppose a programmer needs a verified module which implements a stack of strings. 
By searching the library on the key w'ords “stack'’ and “verified” he might discover that a verified 
module implementing a stack of integers existed in the global library. Assuming he had the proper 
access permissions, he could then make a copy of this module in his workspace and modify it to imple- 
ment a stack of strings. The programmer may be able to reuse more than just the source code for the 
module. The proof data and any associated documentation could also be retrieved, modified, and reused 
in the new development. 

5. Implementation 

A prototype implementation of ENCOMPASS is being constructed on a Vax running BSD 4.2 
UNIX. ENCOMPASS is designed to be an extension of the UNIX environment, so standard software 
tools can be used. ENCOMPASS currently encorporates standard editors, text processors, compilers, 
linkers and many other tools. Language-oriented tools for PLEASE are being constructed with the 
SAGA meta-tools. For example, a language-oriented editor for PLEASE is created from a BNF descrip- 
tion of the language. Other language-oriented tools being constructed include an interactive tool to 

3 

For example a module might have met technical review standards, be well tested, be proven by a period of 
use, or possibly even be formally verified with respect to its specification. 
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transform PLEASE programs into executable form and a verification condition generator. 

The configuration control tools and the hierarchical library structure are implemented using a 
representation of our configuration model on the UNIX file system[21j. The representation uses files to 
represent simple entities, directories to represent modules and projects, and symbolic links** to represent 
complex relationships. For example, a directory representing a module may contain files representing 
simple entities such as the specification of the module, the body of the module, the object code, and pos- 
sibly the load module. A number of tools have been written which use the underlying directory struc- 
tures. For example, complex entities can be moved and copied as single units. A version of any entity 
can be saved using the RCS revision control system[45]. For complex entities a table containing the ver- 
sions of all the sub-components is stored. 

The use of symbolic links simplifies the interaction of the configuration tools and existing systems 
components. By implementing references between modules by symbolic links, tools such as a compiler 
can directly access the required source needed for the compilation and existing compilers can be used in 
our environment without alteration. Another benefit of the use of symbolic links is that the makefile for 
a module only needs to search the current directory for source dependencies. Therefore, the makefile 
can use pattern matching techniques to access all the relevant files in a module and does not have to be 
rewritten every time the modularization of the program is changed. 

The workspaces and libraries are implemented as directories, which are owned by the person who 
controls them. These directories contain sub-directories, files and symbolic links with the meanings 
given above. Views are implemented as directories containing symbolic links. References from 
workspaces, through views, to components in the project and global libraries are implemented as chains 
of symbolic links. Views are created and modified by esh scripts which are saved and run by project 
leaders. If a view references a particular version of an entity, rather than the working copy, the version 
is checked out of RCS into a special area of the library when the view is created. This structure has 

^ A symbolic link contains the name of the file to which it is linked. Symbolic links may span file systems and 
may refer to directories. The file to which the link refers need not exist at the time the link is created. 

^ Csh is a command interpreter on UNIX which supports many of the features found in modern programming 
languages. A sequence of shell commands may be saved and run as a program. 
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been used to support PLEASE, Path Pascal, C, Pascal and csh programs. 


6. Future Work 

Although ENCOMPASS is independent of the language used for development, currently all the 
language-oriented tools are being constructed for PLEASE and Path Pascal. We plan to apply our exe- 
cutable specification method to ADA and create the language-oriented tools to support it. We plan to 
extend the notion of versions used in ENCOMPASS to differentiate between sequential revisions and 
parallel alternatives. A revision supercedes the component from which it was created, while an alterna- 
tive provides a choice between component. For example, different alternatives of a program can be 
maintained for use with different operating systems. Each alternative passes through a series of revi- 
sions as it evolves. 

Presently the configuration control tools in ENCOMPASS can only be used on projects which fol- 
low certain conventions for directory structure. We would like to extend the implementation of 
ENCOMPASS to allow its use with any pre-existing directory structure on UNIX. We would also like to 
extend ENCOMPASS to support aggregation hierarchies of arbitrary complexity and a generalized 
hierarchical library structure. We plan to use ENCOMPASS to maintain itself, and to develop several 
new software tools. We hope that this experience will give us new insights which will be incorporated in 
future versions of ENCOMPASS. 

7. Summary and Conclusions 

ENCOMPASS is an example software engineering environment being constructed by the SAGA 
project to support a particular model of the software life-cycle and software configurations. In ENCOM- 
PASS, the software life-cycle is viewed as a sequence of developments, each of which reuses components 
from the previous ones. An executable specification language is used so that programs are available for 
experimentation, evaluation, and validation as early as possible in the development process. ENCOM- 
PASS supports the Vienna -Development Method, in which a system is constructed by first producing a 
specification in an executable specification language and then incrementally refining it into a program in 
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an implementation language. Each refinement produces an executable program which may be used as a 
prototype system. By producing a running system early and often in the development process, design 
and specification errors can be detected and corrected earlier and at lower cost. 

The components in a software system are modeled as entities which have relationships between 
them. An entity may have different versions and different views of the same project are allowed. 
ENCOMPASS supports multiple programmers and projects using a hierarchical library system contain- 
ing a workspace for each programmer; a project library for each project, and a global library common to 
all projects. By dividing the life-cycle into a sequence of small steps, using a rigorous model for the com- 
ponents produced and used, and incorporating a hierarchical library structure, ENCOMPASS should 
enhance the tracking, evaluation and management of software projects. 
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